fix(review): defer R coverage on any declared dependency, not only Suggests - #721

…ggests

The central coverage-evidence R deferral could turn a transient sandbox
dependency-install flake into a hard REQUEST_CHANGES, blocking every R
package that Imports a heavyweight dependency (mirt, lavaan, ...).

Root cause: r_coverage_peer_gate.py's classify-testthat deferral only
admitted packageNotFoundError failures for the package under test plus
its DESCRIPTION `Suggests` field. But a package's testthat suite loads the
package under test, which requires its `Imports`, `Depends`, and
`LinkingTo` too. aFIPC declares `Imports: mirt` (not Suggests), so when the
sandbox failed to install mirt the failure named `mirt` -- outside the
allowed set -- and the classifier rejected the deferral. run_r_package_testthat
then took the FAIL branch, never emitted the deferral marker, and the
require-check gate that would have found the green current-head R CMD check
was never reached. coverage-evidence reported `failure` and OpenCode posted
REQUEST_CHANGES, even though the repo's own R CMD check was green on the head.

Fix: replace `declared_suggests` with `declared_dependencies`, which unions
the `Depends`, `Imports`, `LinkingTo`, and `Suggests` fields (Enhances is
excluded on purpose -- those packages are not loaded when the package under
test loads). Field parsing stays per-field and fail-closed: a duplicate
field, a malformed package spec, or a non-indented line without a colon
inside an open field body still returns None, and any one malformed
dependency field fails the whole deferral closed.

This does not weaken the gate. Approval still requires (1) every failure to
be a clean packageNotFoundError condition, (2) the missing package to be a
DECLARED dependency in the DESCRIPTION snapshot taken before untrusted tests
run, and (3) a successful current-head peer R CMD check that actually
installed the dependencies and ran the real suite. The change only stops a
declared-Imports install flake from being misclassified as a code defect.

Verification: full tests green (806 passed), scripts/ci coverage 100%
(r_coverage_peer_gate.py 133/133), interrogate 100%.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzUnTqFnQqhRbaopvDdag7

…btqxja

…btqxja

`scheduled-security-scan.yml` pinned `codeql-action/init` and `analyze` to
v4.37.0 (99df26d4) while `upload-sarif` was already bumped to v4.37.4
(f205ea1c) — a partial Dependabot bump. The
`test_codeql_action_steps_use_one_version_per_workflow` contract test requires
one CodeQL action ref per workflow (mixing init/analyze/upload-sarif versions
can fail PR analysis), so the suite failed 805 passed / 1 failed. Because the
central coverage-evidence gate runs the full test suite, this failure blocked
approval for every .github pull request, including this one.

Align init and analyze to the SHA upload-sarif already uses (f205ea1c,
v4.37.4). No new SHA is introduced — this is the ref already trusted in the
same file. Full suite now 806 passed; the contract test passes.

This lands alongside the R coverage-deferral fix on this branch because the
one-branch-per-repo workflow requires it and this failure was blocking that
change's own coverage-evidence.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzUnTqFnQqhRbaopvDdag7

Head 2378e71 reverted the earlier CodeQL SHA alignment (b6ea84f), so
`scheduled-security-scan.yml` again mixed CodeQL action refs: init/analyze at
`99df26d4…` (v4.37.0) while upload-sarif carried the partial Dependabot bump to
`f205ea1c…` (v4.37.4). `tests/test_codeql_pr_workflow_contract.py::
test_codeql_action_steps_use_one_version_per_workflow` fails on that split
(a workflow's CodeQL init/analyze/upload-sarif must share one release), which
made this PR's `coverage-evidence` job report `1 failed, 805 passed` and blocked
OpenCode approval at the current head.

Align init (L93) and analyze (L99) up to `f205ea1c…` (v4.37.4) to match this
file's own upload-sarif, keeping the newer (security-bumped) release and leaving
codeql-pr.yml (internally consistent on v4.37.0) untouched.

Verified: `pytest tests/test_codeql_pr_workflow_contract.py` 3 passed; full
`pytest tests` 806 passed. Pure workflow-YAML change — coverage and interrogate
docstring evidence are unaffected (both already PASS in the coverage-evidence log).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzUnTqFnQqhRbaopvDdag7

… cryptography)

pip-audit (--strict) reported 4 known vulnerabilities in the Strix CI lock at
this head, which fails the pip-audit and dependency-review gates and blocks
auto-merge (the CVEs were disclosed against the pinned versions; they affect
base main too):

  aiohttp 3.14.1
    CVE-2026-59881  RSV1-bit decompression w/o permessage-deflate  (fix 3.14.2)
    CVE-2026-69243  WebSocket-upgrade request smuggling             (fix 3.14.2)
    CVE-2026-69244  OOB heap read in the C response parser          (fix 3.14.3)
  cryptography 49.0.0
    CVE-2026-69247  pkcs7 decrypt padding-oracle                    (fix 50.0.0)

Fix: bump the direct pin cryptography 49.0.0 -> 50.0.0 and add a transitive
floor aiohttp>=3.14.3 (pulled via strix-agent) in the requirements-strix-ci.txt
input, then regenerate requirements-strix-ci-hashes.txt with the exact recorded
command (uv pip compile --generate-hashes --python-version 3.13
--python-platform x86_64-manylinux_2_28). Resolves cleanly (103 packages); no
other pins change to a vulnerable version.

Verified: uv resolve picks aiohttp==3.14.3 + cryptography==50.0.0; pip-audit
--strict on the regenerated lock (Python 3.12, CI parity) -> "No known
vulnerabilities found"; full `pytest tests` -> 806 passed (no contract-test
drift).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzUnTqFnQqhRbaopvDdag7